home *** CD-ROM | disk | FTP | other *** search
- Path: Hermes.grace.irl.cri.nz!maths!peterm
- From: peterm@maths.grace.cri.nz (Peter McGavin)
- Newsgroups: comp.sys.amiga.programmer
- Subject: Re: Demo/game to OS friendly part II
- Date: 31 Jan 1996 23:33:38 GMT
- Organization: Industrial Research Ltd
- Message-ID: <PETERM.96Feb1123338@tui.maths.irl.cri.nz>
- References: <john.hendrikx.47u5@grafix.xs4all.nl>
- <PETERM.96Jan29164036@tui.maths.irl.cri.nz>
- <4ek6bo$84n@xmission.xmission.com> <4ekl5d$51@serpens.rhein.de>
- NNTP-Posting-Host: tui.grace.cri.nz
- In-reply-to: mlelstv@serpens.rhein.de's message of 30 Jan 1996 09:33:49 +0100
-
- mlelstv@serpens.rhein.de (Michael van Elst) writes:
- >butlerm@xmission.xmission.com (Mark David Butler) writes:
- >>For backward compatibility you could have an AUTOSYNC mode where all
- >>graphics operations are executed synchronously.
- >
- >Not really necessary as graphics operations _are_ already async now.
-
- Current high-level gfx calls have a queue limit of 1 (or less than 1).
- BTW: What is the correct way of waiting for an async gfx operation to
- complete? One could use OwnBlitter()/WaitBlit()/DisownBlitter(), but
- it's not always clear whether the blitter is used.
-
- On the other hand, QBlit() is too low-level (insists on hardware
- register banging).
-
- >One problem with message passing is overhead of task switches.
-
- I agree. However task switches are not a problem for large gfx
- operations like copying an entire bitmap. This is akin to a large IO
- request in DOS. Perhaps the system should have a mechanism for
- batching trivial gfx operations, something like buffered IO in DOS.
- --
- Peter McGavin. (p.mcgavin@irl.cri.nz)
-